IBIS Macromodel Task Group

Meeting date: 29 October 2019

Members (asterisk for those attending):
ANSYS:                        Dan Dvorscak
                              Curtis Clark
Cadence Design Systems:     * Ambrish Varma
                              Ken Willis
                              Kumar Keshavan
Intel:                        Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                              Radek Biernacki
                            * Ming Yan
                            * Todd Bermensolo
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology:            Randy Wolff
                            * Justin Butterfield
SiSoft (Mathworks):         * Walter Katz
                              Mike LaBonte
SPISim:                     * Wei-hsing Huang
Teraspeed Labs:             * Bob Ross

The meeting was led by Arpad Muranyi.  Justin Butterfield took the minutes.

--------------------------------------------------------------------------------
Opens:

- None

-------------
Review of ARs:

- Walter to send the latest BIRD198 syntax and examples proposal to Bob,
  Randy, Arpad, and Mike L.
  - Arpad reported this is done.
	
- Randy to draft a new response to the BIRD198 authors.
  - Arpad reported this is done.

- Ambrish to send the BIRD197.5 proposal to Randy.
  - Arpad reported BIRD197.5 was introduced in the last Open Forum meeting.

- Randy to notify the Open Forum and post BIRD197.5.
  - Arpad noted BIRD197.5 was posted.
  
- Walter to send out draft 2 of the BCI for Statistical BIRD.
  - Arpad reported this was done.  Walter noted he sent out a draft 3.

  
--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the October 15
meeting.  Walter moved to approve the minutes.  Bob seconded the motion.
There were no objections.

-------------
Enabling Back Channel Interface in statical mode:
Walter noted there are three ways to implement statistical iteration between the 
Tx and Rx.  The first is a new AMI_Impulse function.  The second method is to 
use AMI_Init.  And, the third is to use AMI_GetWave.  Walter stated he did not 
like to use AMI_GetWave, and others did not like the idea of AMI_Impulse.  So, 
he changed the BIRD draft to use AMI_Init.  The change is to the memory handle 
to act like *AMI_memory that would have already been allocated.  We now have a 
choice to use the BIRD147 AMI_GetWave method, which uses a file set by the 
BCI_File and uses a file I/O method.  He added a new concept, which is to have 
AMI parameters out that have a special branch for BCI called "(BCI...)".  The 
content of the branch would be defined by the protocol.  The EDA tool would take 
the memory pointer for the Tx and make it the BCI parameter input for the Rx.  
If the BCI branch is used, the Rx would use the contents of the output from the 
Tx and ignore the inputs from the AMI parameter input.  The EDA tool would not 
report any of the contents of the BCI branch.

Fangyi asked if the first call to AMI_Init is the regular call to the function.  
Walter stated this is true for both the Tx and Rx.  Fangyi asked what is passed 
to the Tx and what is passed to the Rx, if it is the whole string.  Walter 
stated it is the whole string, as he wanted to make it easier for the EDA tool 
and not require any parsing on the tool side. The protocol determines the 
contents of the string.  The difference between using this technique is the 
performance, since file I/O might not be very reliable between multiple tasks.  
The size of the data may also affect the simulation performance, where file I/O 
could be significantly slower.  Wei-hsing agreed file I/O could be a problem 
when the file gets closed.  

Wei-hsing suggested the Tx could become a pass-through, while the Rx is trained 
initially.  He thought you could use the API directly to communicate.  The API 
needs to be known between the Rx and Tx.  Ambrish asked if the EDA tool is the 
best place to mediate between the Tx and Rx.  Wei-hsing replied the API would 
have to be defined between the functions to optimize directly.  Ambrish stated 
you need to now the names of the models.  Walter commented there are some tricky 
things as you need to know the memory handles for the models.  Fangyi asked how 
the Tx DLL would know the location of the Rx DLL once these are already in 
memory.  Wei-hsing stated a file would be written to know the output then use 
the output from the Tx pass-through and call the Rx model which will talk to its 
own copy of the Tx.  The model makers would need to be careful when using static 
variables which may be contaminated in this process.  There would be two phases 
to the training.  The first phase is when the Tx is a pass-through.  Once the 
data is generated, the Rx can load a proxy of the Tx and do the iterations to 
write out the training result.  When the file exists, the training is done and 
the normal simulation can be run.

Fangyi asked, in Walter's approach, if the AMI parameter out is first allocated 
by the Rx.  Walter replied the Rx will first use the normal branches, then the 
BCI branch would be allocated.  And, this would be used by the Tx.  Fangyi 
commented the Tx would keep its own copy of the memory.

Fangyi asked what happens if you have two copies of the Tx and Rx models.  He 
asked how the training configuration files would be used.  Wei-hsing replied 
there would be separate models.  Fangyi asked how the proxy models would be 
named and how to map the proxy models to the real models.  Wei-hsing stated, at 
the end of the training stage, the configuration file is written out and used in 
the simulation directly.  There should be a way to do this.  Arpad suggested the 
DLL_ID could be used for this.  Fangyi asked if at the end of the simulation the 
file would be deleted.  Wei-hsing replied, yes.  Arpad commented we could still 
use Walter's idea to communicate without a file.  Fangyi stated, in Walter's 
approach, we do not need to worry about multiple instances.  Fangyi asked, since 
the dummy Tx allocates the memory, who closes the memory.  Arpad asked, when the 
Tx dummy is loaded, how the AMI parameters are loaded by the Rx.  Wei-hsing 
replied there could be many ways to pass in the parameters in separately.  
Walter commented there are some details to work out for repeaters.  

Walter noted we would need to make some decisions on the direction whether we 
want to use file I/O, branches, or come up with another scheme.  Walter 
suggested we should decide a path.  He has written up his idea with sufficient 
detail.  The idea of the proxy models is a bit more complicated, since the 
concept would have to be clear to model makers.  Arpad agreed we should make a 
decision.  He agreed Wei-hsing's approach would be more efficient for the EDA 
tools.  Arpad asked if Wei-hsing can write up how this would work.  Ambrish 
asked if this would need any changes to the specification, and he suggested we 
could have a white paper on this.  Wei-hsing will create a slide to show how the 
pass-through Tx model training approach would work [AR].  Walter noted he would 
like to see both cases of the Rx train the Tx and the Tx train the Rx.


Arpad asked if we should cancel the meeting next week.  Walter and Ambrish 
agreed with canceling the meeting.

- Ambrish: Motion to adjourn.
- Walter: Second.
- Arpad: Thank you all for joining.

AR: Wei-hsing to create a slide to show how the pass-through Tx model training 
    approach would work.

-------------
Next meeting: 12 November 2019 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
